Many enterprises operate from a number of different locations. They may have networks such as Local Area Networks (LANs) operating at each location. It is often desirable for such enterprises to interconnect these “satellite” networks so that all users can access resources from all of the satellite networks. To such users, it would appear that the enterprise operates a single network incorporating all of the satellite networks.
This can be facilitated by the use of a Virtual Private Network (VPN). A VPN is a communications network “tunnelled” through another network. One common application is secure communications through the public Internet, but many other applications can be envisaged.
Different VPN service models have been proposed over the last several years in order to satisfy diverse requirements. These models include traditional Frame Relay or Asynchronous Transfer Mode (ATM) VPNs, customer equipment based VPNs, such as those using Layer 2 Tunnelling Protocol (L2TP) and/or IP Security (IPSec) and provider provisioned VPNs (Layer 2 (L2) and Layer 3 (L3) VPNs). In the provider provisioned network based L3 VPNs, Provider Edge (PE) routers contain the VPN functionality needed to transfer L3 (IP) traffic between different sites of a customer.
L3VPN technology has many potential uses, including in the Internet. Furthermore, the 3rd Generation Partnership Project (3GPP) is discussing a Long Term Evolution (LTE) wireless communication standard, in which the core network architecture is known as System Architecture Evolution (SAE). The backbone networks for this architecture may well be IP-based, and it can be envisaged that VPNs may be required for applications such as core network nodes for signalling or Operations, Administration and Maintenance (OAM) traffic; base stations for radio signalling or OAM traffic; base stations, SAE Gateways (GWs) and Mobility Management Entities (MMEs) within the same pool; all non-3GPP serving nodes; fixed access edge routers; and Video on Demand (VoD) servers and clients.
FIG. 1 depicts a general schematic view of a PE-based, provider provisioned L3 VPN architecture. Four LANs 11-14 are connected to a provider's IP network (backbone network) 15. Two of the LANs 11, 12 belong to a first customer, and are linked to provide a first VPN. The other two LANs 13, 14 belong to a second customer, and are linked to form a second VPN. Each LAN includes a Customer Edge (CE) router CE1-CE4. The backbone network 15 includes two PE routers PE1, PE2, to which the CE routers CE1-CE4 are connected. The backbone network further includes Provider (P) routers P1-P5 that forward data (including VPN data), but which do not provide VPN functionality to the CE routers CE1-CE4.
An IP packet 16 is sent from a source node (not shown) within a LAN 11 belonging to the first customer, and is intended for a destination node (also not shown) within the other LAN 12 of that customer. The packet 16 contains an IP payload 17 and destination IP address information 18. The packet 16 is sent from the CE router CE1 at the edge of the LAN 11 to an “ingress” PE router PE1. The package is encapsulated, and inner and outer headers 19, 20 added, to route it, via P routers P1, P2 to an egress PE router PE2. At the egress router PE2 the inner and outer headers 19, 20 are removed. The packet is then forwarded to the CE router CE 2 at the edge of the second LAN 12, and on from there to the destination node within the second LAN.
Two provider-provisioned L3VPN solutions have been proposed in recent years. The first is the Border Gateway Protocol/Multi-Protocol Label Switching (BGP/MPLS) VPN described in RFC 4364 and U.S. Pat. No. 6,339,595. The second is the Virtual Router based IP VPN described in the ietf draft “Network based IP VPN Architecture Using Virtual Routers”, March 2006.
Two issues have to be handled by a “provider provisioned” L3 VPN, such as that shown in FIG. 1. The first issue is that the addressing within VPN sites (e.g. the LANs 11, 12 shown in FIG. 1) may be such that their private address spaces overlap. The second issue is that P routers are not aware of VPN addressing and are not directly capable of routing traffic to a VPN internal address.
The first issue means that the IP header's destination field of the packet received from a customer is not enough to route the packet. Overlap is handled using different forwarding tables (Virtual Routing and Forwarding tables (VRFs)) for different VPNs and encapsulating (tunnelling) VPN data packets (using the inner header 19 shown in FIG. 1). Based on the inner header 19, the egress PE router PE 2 can look up the packet destination address in the appropriate VRF. In the BGP/MPLS VPN this inner header 19 is an MPLS label, while in the Virtual Router based VPN any encapsulation method can be used (e.g. IP-in-IP, IPSec, Generic Routing Encapsulation (GRE)). However, the main difference between these methods is how PE routers exchange routes of a particular VPN.
FIG. 2 is a schematic illustration of a BGP/MPLS VPN arrangement. Similar elements to those of FIG. 1 are represented with the same reference numerals. VPNs for two customers (#1 and #2) are shown. The ingress and egress PE routers PE1, PE 2 are connected to the CE routers CE1-CE4 (not shown in FIG. 2). Each PE router contains a VRF (#1, #2) for each VPN (#1, #2). BGP with Multiprotocol Extensions (MP-BGP, described in RFC 2283) 21 is used to exchange routes for each VPN (#1 or #2). This involves exchanging the routes using the VPN-IPv4 address family. This address family contains, besides an IPv4 address field, a Route Distinguisher (RD) field which is different for each VPN. This ensures that, if the same address is used in several different VPNs, it is possible for BGP to carry several completely different routes to that address, one for each VPN. The relevant VRF is identified by an inner Label Switched Path (LSP) label 22 which is appended to the IP packet.
FIG. 3 is a schematic illustration of a Virtual Router (VR) based VPN arrangement. In this case, not only a VRF is allocated for each VPN, but a whole routing instance 31 that emulates all the functionality of a physical router. Routing information is exchanged between VRs of the same VPN using the same tunnels 32 as those used by VPN data flow. Therefore the forwarding tables of virtual routers can be populated using any standard routing protocol (e.g. BGP, Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS)). However in order to enable a PE to dynamically discover the set of remote VRs which are in common VPNs, and in order to discover the connectivity between these VRs, BGP-4 multiprotocol extensions have also been proposed in “Using BGP as an Auto-Discovery Mechanism for VR-based Layer-3 VPNs”, September 2006. These are similar to the BGP/MPLS VPN solution discussed above.
The second issue that has to be handled by a provider provisioned L3 VPN is that P routers should not maintain VPN site related routing information, i.e. packets cannot be routed based on VPN sites' private IP addresses. Using only the inner header for this purpose, the number of routing states in P routers would be related to the number of VPNs and the number of their sites. In order to overcome this, in both VPN solutions an outer tunnel 23 is proposed, and any encapsulation method can be used for this purpose (e.g. MPLS, IP-in-IP, GRE, IPSec).
A special case of the Virtual Router based VPN is when PE routers are directly connected using an Ethernet network. In this case the outer header is not needed and the virtual LAN (VLAN) tag (defined in IEEE 802.1Q) can be used as an inner header in order to separate the VPNs in the provider's network. This architecture can be achieved for instance with current Juniper or Cisco products using the so-called Multi-VRF feature (“Building Trusted VPNs with Multi-VRF)”.
Thus the most commonly used VPN technology, BGP/MPLS VPN, relies on MPLS functionality in the PE routers. The alternative is to use a virtual router approach, which eliminates the LSP requirement for the inner header. However, it has scalability limitations since, for each VPN, a different routing instance 31 (a different routing daemon) runs in the PE router. Moreover it requires the manual configuration of the inner tunnels 32 (an IP-in-IP or a GRE tunnel needs the configuration of two tunnel endpoint virtual interfaces, both of them with at least 3 parameters), which enormously increases the configuration complexity compared to BGP/MPLS VPN. The Multi-VRF solution does not require the configuration of bi-directional tunnels, but suffers from similar scalability limitations to the virtual router concept. In addition, it requires that the PE routers are directly connected with a L2 Ethernet network.